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[This month I have handed over responsibility for AUUGN content 
to a guest editor. So don't blame me! Bob Kummerfeld 3 


Hello, I'm Karlos Mauvtaque, UNIX 1 enthusiast, seventh Dan rogue player, 
four times total winner and founding member of the Australian Unix Red Wine Users 
Group (AURWUG). And I'm your user-friendly menu-driven guest editor. 

Well '82 has sure turned out to be a good year. Those keen lads at UCB 
announced 4.2bsd, destined to change the way the disks spin (remember the secret 
is to bang the rocks together guys). Innovation in operating system design and 
implementation has long been a research interest of mine and included in this 
issue is my analysis of what lies in writable-control-store for us in 4.3bsd. 

'82 has also been a great year for vendors. Many interesting non-commercial 
sales pitches were seen this year at AUUGMs. It seems that the dawn of 
engineering excellence is upon us. Zillions of UNIX look-a-like, smell-a-like 
and C-a-like systems are upon us. Onyx, Unos, Unison, Zenix, and Buttix, all of 
them were there in force; crashing merrily and scribbling on their respective 
file-systems. All of them solving the fundamental UNIX short-coming - a poor 
choice of command names like "rm" and "dsw". 

'82 has also been a great year for the absurd. There was that absurd 
Californian who taught us all about paging page table entries, and how we'll all 
make a lot of money selling memory or something. There was the absurd in-place 
file system conversion suggestion from Mr Level-6.92. There was the absurd tee- 
shirt bonanza from a leading "buy our machines" vendor. And there was the Red 
Capsicum incident. Well enough said about that. 

What lies ahead of us? Read on... 


***************************************************************** 


* * 

* SUBSCRIPTION FEES NOW DUE * 

* * 

* This will be your last issue of AUUGN unless you * 

* send $24 to the address shown on the back cover. * 

* * 

* Support the Unix community - share your experiences. * 

* Send an article about what YOU are doing. * 

* * 


***************************************************************** 


1 UNIX is a trademark of Bell Laboratories. 
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[This article was inherited from Chris Rowles who has defected to 
PSYROMAHHT. No responsibility is assumed for it. It wa 3 written in pigeon ms 
and wouldn't compile let alone run. I have beaten it into shape and chased after 
a title and author. The current belief is that it appeared in EUUGN last year. - 
KM] 


An Evaluation of ONYX 
Alan Mason 

Introduction 

Thanks to the cooperation of Scan Computer Systems Ltd., an Onyx C8002 
system was installed in the Edinburgh University Architecture Department, 
alongside the existing PDP11/60 installation, for 2 days. Members of the EdLUUG 
were given free access to the system, and this is the result of their 
experiences. Many thanks are due to Joel Abramson and Phred Groves, of Scan, for 
their patient tolerance of the activities of the assembled throng. 

Hardware 


The system supplied had 512K bytes of main memory, and a single IMI 8-inch 
winchester disk, of 18M bytes formatted capacity. This hardware costs in the 
region of 11K pounds. Scan promise upgrades of 1M bytes of main memory, and to 
40M and 100M bytes (unformatted) of disk, both to be installed in the same box. 

The hardware was installed by plugging it in, attaching the terminals, and 
turning it on. The only thing to disturb its equanimity for the 2 days was the 
application of large doses of static, which interrupted the kernel. For most of 
the time, it ran with the cover lifted, though we were assured that this was 
purely to satisfy the curiosity of the on-lookers, not to cure heating problems. 
The relatively small room, in which was installed the Onyx system, an LSI 11, an 
Apple, 7 terminals, and many people, got uncomfortably hot without causing 
problems.. 

Kernel 

The licence for the software supplied costs in the region of 2K pounds (for 
8 users). The kernel appeared, as far as we could determine, to implement all 

1 2 

the system calls of V7 UNIX correctly , plus a' few others. Apart from the 
static interruptions, the kernel ran reliably. It is relatively large (98K 
bytes), but this still leaves 414K bytes for user programs. 

The kernel comes as a single file, "onix.o", together with an embryo library 
for extra, user-specific device drivers. The system ”.h" files, including 
"param.h" are available, but changing them won't have much effect* However, the 
disk layout is declared in "c.c", so this can be changed. Much aggravation was 
caused by the Bell teletype driver, particularly because of its lack of paging, 
and inability to erase characters correctly from the VDU screen. An attempt will 

1 UNIX is a Trademark of Bell Laboratories. 

2 Except "sysphys" and "syslock”, neither of which 
are widely used. 
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be made to persuade Onyx to supply the EUUG driver as an alternative, or to 
supply the system as libraries. 

Stack growth is not performed by the hardware intercepting and backing-up 
segmentation violations, but by a system call "ugrow". The "csave" code checks 
for segment boundary transgression, and calls "ugrow” as appropriate. All 
segmentation violations are signalled. If "ugrow" fails to obtain more stack, 
the process concerned receives signal SIGSEGV as expected. Thus, there are no 
"backupO" problems, provided that your language compiler understands the 
convention. However, the extra computation is an overhead on "csave" for all 
function calls, which is probably a significant drag on the overall performance. 

Floating point support was so slow that is was initially assumed that it was 
being dony by software. Typical floating-point add times were 0.3ms, and 0.45ms 
for double-length. However, we have since been told that the system does use the 
floating-point hardware, but the overhead of synchronising the two processors is 
sufficient to account for the timings. 

Utilities 

c 

init As usual with Bell V7 systems, the system arrives after a boot with a 

root shell in single-user mode. When the console logs out, it then 
executes "/etc/rc" and goes multi-user. Of course, this effectively 
nullifies all UNIX's file protection and security features. Anyone who 
can obtain access to the console and the power switch can access, and 
destroy, any file. Although our systems have been modified to overcome 
this problem, applying this solution to systems without a removable 
disk might be risky. It was reputed to be possible to boot a system 
from the cassette tape, but Scan had encountered some problems in this 
area. 

C The machine had two C compilers. The earlier compiler, called "cc", 

appeared to be a descendant of the Ritchie PDP11 compiler. It appeared 
to implement the language defined in the C book but did not implement 
structure assignments. It did not support the data types "float" or 
"double" at all, failing with mysterious messages such as 

0: Intermediate File Error 

when values of these types were declared. The code it produced seemed 
to be about 70% bigger than code compiled with "cc -0" on a PDP11. It 
even has the token "pdpll" defined! It sometimes dumped core when 
compiling standard C programs. 

The more modem compiler "zee" did implement structure assignment and 
floating point arithmetic, but excluded bit fields and static function, 
both of which are in the C book specification. The code it generated 
was about 20-25% bigger than the corresponding code from "cc -0" on a 
PDPll. This improvement may have been due to the optimiser with which 
it was provided. The object modules it produced always had instruction 
and data spaces separate. The pre-processor for "zee" was incompatible 
with that for "cc", particularly as regards comments on "/define" 
lines. In general, it seemed even less reliable than "cc", being 
obviously in an early stage of development. It was inclined to expire 
in a cloud of error messages, obviously intended more to debug the 
compiler than to debug the program. Even more seriously, it sometimes 
appeared to compile programs which then failed to execute correctly. 
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We have since been told that its author is Dennis Allison, of Stanford. 

adb Adb was capable of symbolic output as Z8000 assembler, except that the 

system calls were wrongly interpreted, but the documentation still 
described the PDPll version. There was no documentation whatsoever on 
the Z8G00 assembler, and Onyx appear reluctant to provide it, even 
claiming that they don't have it themselves! It is difficult to see 
how "adb" can be useful without this information. 

nroff Nroff worked on fairly large documents using the "-ms” macros, and the 
"tbl" preprocessor. However, the terminal driving tables were the 
standard Bell set, not very useful for normal UK purchasers of daisy- 
wheel printers. Of course, without the source code it is a bit 
difficult to construct your own. 

yacc Yacc worked on a single, fairly small, grammar. 

lex Lex worked on a single, very small, grammar. 

make Hake worked on a fairly complex "makefile". However, it revealed a 

problem with "touch” which always returns a failure error code. 

pas This UCSD Pascal compiler proved reasonably satisfactory. It includes 

ISAM support, which is linked into the user program irrespective of 
whether it is used. With separate I/D space in use, the ISAM support 
moves to I-space and leaves about 60K bytes for user programs and data. 
Without this option, only 48K bytes are available. The following 
incompatibilities were noted:- 

- The user must explicitly "stty cbreak" to enable character level I/O 
to function as UCSD expects; this should be done by the run-time 
support. 

- The KEYBOARD device is connected to the UNIX file "stderr". This 
does not make sense, since KEYBOARD is an input device and "stderr" 
is an output device. Programs using KEYBOARD do not work at 
present. 

- The CLOSE-CRUNCH option is not implemented, but in addition the 
CLOSE-PURGE option fails to remove the file. Opening a file with a 
specific length, as "FILE.TEXTnOl” includes the length specifier in 
the file name. 

- The include pragma ($1...) does not appear to find the include files 
even when the full path name is supplied. 

- The use of segment procedures had no effect on the available space 
for user programs; they must be held in memory rather than swapped 
on demand. 

- Separate compilation UNITS are not supported. 

Performance 


From running the 'benchmarks set out in another paper, we concluded that the 
system performed better than a 248K byte 11/34 with a Fujitsu disk, but not as 
well as the same machine with an 4K byte cache. 
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During the 2 days, we did at one time have all 8 ports logged-in, but 
normally ran with 5-6 people logged in. At that level, it was noticeably slower 
than the 11/60 with an equivalent load, but was perfectly acceptable. The system 
should be fully capable of supporting 8 normal University users. 

The benchmarks reveal some interesting aspects of the system's performance. 
In particular, creating a process takes much longer than on a PDPll, This may be 
due to cache turnover problems; in addition to the in-core disk cache (only 18 
blocks), the disk controller maintains a cache of something like 100 blocks. 

Conclusions 


Broadly, our conclusions are favourable. The combination of the hardware 
and the kernel provides a reliable 8-user timesharing system, with wholly 
adequate performance. This system costs less than four average single-user 
systems, yet provides better performance and a vastly superior software 
environment. Most of the utilities functioned as expected, and the Pascal system 
seems to provide software compatibility with existing UCSD systems. 

On the other hand, we have two major reservations about the software. 
Firstly, neither of the two C compilers are remotely acceptable. It is clearly 
impossible to move the body of applications code we have developed to this system 
using either compiler. We hail to understand why the Portable C compiler was not 
used to make the port of UNIX, or why it has not yet been made available, 
especially since this would also provide "f77" and "lint". 

Secondly, providing the system as a single object module makes it impossible 
to change. This is particularly objectionable as regards the teletype driver. 
UNIX users in Europe, and to some extent in the US, have for many years rejected 
the Bell driver. In particular, the EUUG distribution of V7, which is used in 
the majority of European V7 sites, includes the driver upon which all our 
communications developments are based. We would find it difficult to accept any 
system which did not permit us to use this driver. 
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IMPORTANT ANNOUNCEMENT 


IMPORTANT ANNOUNCEMENT 


Special Issue of AUUGN on 
UNIX for Computer Science Teaching 


Editor : Judy Kay 

We are seeking submissions in a wide range of topics that come 
under this subject. In particular, we plan to print reports in the 
following areas: 

. good novice environments available under UNIX 
. tools that are useful in teaching and administration 
in student student environments 
. automatic grading systems 

. experience with cornpilers/languages available 
under UNIX (eg. pi and pc Pascal, f77, euclid, 

Cobol) 

experience with editors available (eg. ed, ded, 
vi, EMACS and structure editors) 

. approaches to security and control 
. other reports of teaching experiences. 


We welcome reports of on-going projects as well as those that 
have been completed. We expect that valuable contributions could 
be provided from non-educat.ional sites and we trust that 
educational UNIX users will deluge us with brilliant articles. 

We are confident that this issue will become a valuable resource 
for the many of us involved in Computer Science teaching. 


Submissions are preferred in camera-ready form by 31st, May, 
1983. They should be sent to: 

Judy Kay, 

Basser Department of Computer Science, F09. 
University of Sydney, 2006.. 


or mailed to judy:basservax 

and you may contact me at (02 5 — 692 — 3525 or 692-3424 
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VMS Version 3 


sultan!dag 


Please stop submitting SPR's. This is our system. We designed it, we built 
it, and we use it more than you do. If there are some features you think might 
be missing, if the system isn't as effective as you think it could be, TOUGH! 
Give it back, we don't need you. See figure. 
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Figure 1. 


Forget about your silly problem, let's take a look at some of the features of the 
VMS operating system. 

1) Options. We've got lots of them. So many in fact, that you need two 
strong people to carry the documentation around. So many that it will be a cold 
day in hell before half of them are used. So many that you are probably not 
going to do your work right anyway. However, the number of options isn't all 
that important, because we picked some interesting values for the options and 
called them ... 

2) Defaults. We put a lot of thought into our defaults. We like them. If 
we didn't, we would have made something else be the default. So keep your 
cotton-picking hands off our defaults. Don't touch. Consider them mandatory. 
"Mandatory defaults" has a nice ring to it. Change them and your system crashes, 
tough. See figure 1. 

3) Language Processors. They work just fine. They take in source, and 
often produce object files as a reward for your efforts. You don't like the 
code? Too bad! You can even try to call operating system services from them. 
For any that you can't, use the assembler like we do. We spoke to the language 
processor developers about this, they think a lot like we do, they said "See 
figure 1". 

4) Debuggers. We've got debuggers, one we support and one we use. You 
shouldn't make mistakes anyway, it is a waste of time. We don't want to hear 
anything about debuggers, we're not interested, See figure 1. 

5) Error Logging. Ignore it. Why give yourself an ulcer? You don't want 
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to give us the machine to get the problem fixed and we probably can't do it 
anyway. Oh, and if something breaks between 17:00 and 18:00 or 9:30 and 10:30 or 
11:30 and 13:30 or 14:30 and 15:30 don't waste your time calling us, we're out. 
See figure 1. 

6) Command Language. We designed it ourselves, it's perfect. We like it 
so much we put our name on it, DCL - Digital's Command Language. In fact we're 
so happy with it, we designed it once for each of our operating systems. We even 
try to keep it the same from release to release, sometimes we blow it though. 
See figure 1. 

7) Real Time Performance. We got it. Who else could have done such a 
good job? So the system seems sluggish with all those priority .18 processes, no 
problem, just make them priority 1. Anyway, realtime isn't important anymore 
like it used to be. We changed our groups name to get rid of the word realtime, 
we told all our realtime users to see figure 1 a long time ago. 

In conclusion, stuff your SPR. Love VMS or leave it, but don't complain. 

-adapted from TOPS-20 
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A note and extension to UBTDT V7 printf s 
the %r format. 

Bob Buckley 

School of Maths and Physics, 
Macquarie University, 

North Ryde, NSW. 


Introduction. 

A few astute hackers may have noticed that the PDP-11 stdio library- 
routine which implements printf, fprintf and sprintf includes code for a 
'%r' format. This undocumented feature is mostly unknown and unused. 

Apart from the lack of documentation, in its distributed form it 
isn't particularly useful. This short article describes a simple 
improvement and demonstrates a sample usage for this feature*. 

The standard '%r' format. 

The original source code (probably the file doprnt.s in directory 
.../lib/libc/stdio) suggests the 'name' of this format is remote. When 
'%r' is encountered in a format string, the corresponding argument is 
assumed to be the address of a vector containing firstly, a pointer to a 
new format string, followed by any arguments which will be needed during 
the processing of the format string. The arguments are assumed to be in 
the same form as they would appear in an argument list passed to a 
procedure (ie. a char is a short, an unsigned is a long, etc. on the 
PDP-11). 

As an example, consider the following program: 

main( ) 

{ 

int vec[2]; 

vec[0] = (int) "a %dnd line\n"; ~ 
vec[l] =2; • 

printf("line %d\n%r", 1, vec); 

} 

When run, this program produces the following output: 

line 1 
a 2nd line 

Of course, lists can be constructed and behave as one would hope. 


* A feature is a bug that looks like it might be useful, eg. most 
'computer manufacturers allow many features to remain in both the 
hardware and software of their computer systems. Heavy use of 
features is probably the best available protection for software - 
it makes it unmodifiable, unportable and unmaintainable. 
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~ 2 - 

Notice, that putting anything after a '%r f has no effect. 

The number of uses for such a feature is limited. Perhaps the most 
sensible is in something like 

error(fmt, a, b, c) 
char *fmt; 

{ 

fprintf(stderr, "error in %s(%d ):%r”, 
filename, lineno, &fmt); 

} 

This is probably the intended usage of this format. However, it is 
potentially more general in its application if the semantics are 
extended slightly. 

An alternative iraplenentation. 

Consider the effect of- making '%r’ recurae rather than remote . When 
the format list and arguments corresponding to a '%r' in a format string 
has been completely processed, formatting continues where it left off .in 
the previous string and argument list. 

For simple cases, the behaviour will be the same as before. But 
more complex structures can now be constructed which allow considerable 
flexibility in format conversion. 

The implementation of this is simple (the biggest difficulty is 
understanding the largely uncommented code in the original assembler 
routine), and the costs are few (about 3 words of stack space for each 
recursion level, about 10 instructions in the routine and a couple of 
instructions in each format conversion at run time). The efficiency 
conscious might want to remove tail recursion though it hardly seems to 
matter. 

An application. 

Of course, this is all pointless unless it is somehow useful. 
Perhaps one of the most elegant uses for this feature is as a 
replacement for 'bundling'*. The mechanism can be used to perform the 
output of complex tree and acyclic graph structures. In particular, it 
can simplify the writing of small compilers and translators. 

Consider the following simple translator for assignment statements 
which directly produces code for a PDP-11. 

%token ASSIGN ADD name 
%{ 

char list[] = ”%r%r", 

assign[] = "%r%rmov (sp)+,*(sp )+\n", 

rv[] = ”%rmov *(sp)+,-(sp)\n", 

add[] = "%r%radd (sp)+, (sp)\n", 

lvlocal[] = "mov r5,-(sp)\nadd $%d,(sp)\n", 

lvstatic[] ="mov $%s,-(3p)\n", 

rvlocal[] = "mov %d(r5), -(sp)\n", 

* BundlingLs a programming technique which compactly represents 
trees of strings. It was described in UNIX V6 TMG and YACC docu¬ 
ments . 
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rvstaticf] = "mov %s, -(sp)\n"; 

%} 

%% 

prog: stlist = { printf("%r", $1); } 
i 

stlist: st 

[ stlist st = { $$ = node(3, list, $1, $2); } 

/ 

st: lv ASSIGN exp =*{$$ = node( 3, assign, $1, $3); } 

/ 

exp: lv = {if($l->op == Ivlocal) 

$l->op = rvlocal; 
else if($l->op == lvstatic) 

$l->op = rvstatic; 

else 

$$ = node(2, rv, $1); 

} 

| exp ADD lv = { node(3, add, $1, $3); } 

f 

lv: name = { switch($l->syntype) { 

case LOCAL: 

$$ = node(2, Ivlocal, $l->offset); 
break; 

case STATIC: 

$$ = node(2, lvstatic, $l->name); 
break; 
default: 

error("bad lv"); 

} 

} 

/ 

Clearly, this doesn’t produce the most elegant code but it was quick to 
write and is simple. It performs at as efficiently as most comparable 
techniques. 

Similar mechanisms can be constructed for many complex data 
structures resulting in easy conversions to external representations. 

Conclusions. “ 

If you are looking for clever programming techniques or corner 
cutting tools, this one may prove useful. This technique was used to 
produce a small compiler for undergraduate teaching. The compiler was 
simple and fast, demonstrating that things need not always be difficult. 
Students had few difficulties in understanding the compiler, and doing 
simple modifications in a single term. 

Of course, this mechanism can be used to produce extremely obscure 
code. It is a technique of little significance, but can sometimes save 
considerable effort. It is regrettable that a corresponding mechanism 
can't be built into the scanf routines. It is also a pity that it is 
difficult to keep portable, 
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Tips for writing programs that won't port to VMS and the DEC C compiler 


R. Grevis 

University of New South Wales 


© As the DEC compiler does not have them, use bit fields fully. Just 
as importantly, use the actual bit field some of the time, and mask 
it yourself the rest of the time, so that removing the bit field 
packing of the declaration will cause the program to fail. 

© Use upper and lower case global names of the same type. The VMS 
compiler and loader do not distinguish case, so havoc can be 
wrought by choosing appropriate naming schemes. A handy idea is 
renaming those temporary local variables like "temp", "i", and "f", 
to be the same as global variable names except in case. The 
compiler won't even detect this error, and they certainly don't 
have DEC lint. ~ 

i The VMS loader requires that space be declared once only, so the 
normal trick of having an include file of var declarations will 
produce a pleasant number of pages from the loader complaining 
about multiple declarations. 

© Use Unix. Stat, dir, and info like that are not avalable as 
transliterating library procedures (DEC softpersons take note if 
you can), so intertwine such things in your code. They are a pain 
in the neck to remove. 

© VMS is set up to detect more overflow conditions, so try to get 
integer overflow occuring whenever possible. The VMS program will 
explode. 

© Simply use the Unix philosophy. Producing processes and pipelines 
easily is a foreign concept to VMS, so write programs which use 
other tools like grep, sort, tail, sed, etc, and also divide the 
problem into separate communicating processes when appropriate. 

If programmers follow the simple rules above, its likely you will 
end up with a Unix portable piece of software which could NEVER run with 
DEC C and VMS without an intimate understanding of what the program 
does. And that should really make those system managers foam at the 
mouth who have just spent $10,000 on a single compiler. 

What can you say?,,. They want C to get some of the tools, and 
that's like dropping a Ferrari engine into a Cadillac. It will sure 
improve the Cadillac, but what's needed is for them to take a step back 
and see what they really should be doing. 
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Long division in UNTX V7 on the LSI-11/23. 


Bob Buckley 

School of Maths and Physics, 
Macquarie University, 
North Ryde, NSW. 


A problem and a solution. 

Once upon a time (several weeks ago) I noticed that our poor little 
LSI-11/23 wasn’t always dividing by 2 correctly. The problem occurred 
when dividing longs. On checking, It I discovered that a very clever 
piece of code was used to implement division of longs by small numbers. 

Unfortunately the clever code comes unstuck as the LSI-11/23 doesn't 
produce the same results as its bigger siblings when overflow occurs 
during a DIV instruction (I had heard rumours that this was the case in 
Europe but hadn't experienced the problem so didn’t take much notice). 
Further investigation revealed that the instruction 'div r3,r0’ on the 
LSI-11/23 was changing the value of rl if the V-bit gets set. It seemed 
that the library routines didn’t expect this. 

Clearly, the only thing to do v/as to consult the Microcomputer pro¬ 
cessor handbook to find out what the differences were. Of course, the 
relevant entry looks like it had been turned into pumpkin scone mixture 
by a computerised typesetting system; so that didn’t help. The supplier 
of the equipment had no idea whether we had a fault or a design 
'feature' as their books are just the same as ours. Next, one tries to 
obtain the information from the manufacturers, but this is futile, as 
they first ask you what operating system you run and from whom you 
bought your computer. As neither answer is particularly pleasing to 
them communication effectively stops. 

Fortunately, the UNIX software is easily fixed. The division and 
remainder routines (these are part of the C runtime library .../lib/crt 
called ldiv.s, aldiv.s, Irem.s and alrera.s; and part of the machine code 
support for the operating system called Idiv and lrem) all deal with the 
low order 16 bits with a sequence of instructions which begins 

div r3,r0 
bvc If 
sub r3,r0 

The routines can be fixed by inserting the instruction 
mov r2,rl 

between the 'bvc' and the v sub’ instruction. 

The code is longer than the original, and a little slower, but 
appears to give correct results on our LSI-11/23. It is quicker and 
smaller than my other attempts at PDP-11 compatible versions of the rou¬ 
tine. Tliis code relies on rO remaining unchanged. The manuals don’t 
seem to guarantee this, so a comment to this effect should be added to 
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the code. If you like using these types of features you might find it 
shorter in the remainder routines to remove the code which deals with 
overflow (rather than inserting the instruction given above) as rl seems 
to have the desired value anyway. Personally, I think this is not a 
very good idea, as it isn’t N upwards compatible 7 . 

What should be done? 

Of course, the routines should be changed in all LSI system 
libraries. All programs which use division of (or by) longs (or 
unsigneds) should be recompiled. 

Other PDP-lls should be checked to see if there are any problems 
with them (has anyone checked the PDP-11/44 yet?). If you are in the 
habit of distributing binaries, then you should fix your library even on 
a PDP-11. As far as I can tell, this code should work equally well on 
all relevant members of the PDP/LSI-11 family. 

I ran into the problem when dividing a long variable by the constant 
2. I was surprised that the compiler didn’t optimise this to a shift. 
Perhaps the compilers "Should be changed to produce shifts and mask 
operations for division and remainders by constants which are powers of 
two in suitable cases. 

We don't have the support routines for unsigned longs on our system. 
I suspect that these suffer the same problem. if you have a working pcc 
on one of these tiny machines then ybu may need to fix these routines as 
well. 

Conclusions. 

The conclusions are many* that assembler code is a pain in the neck 
(the code here was poorly documented and far from clear); toy computers 
usually screw up when asked to do anything that isn't completely basic; 
etc. More importantly, many systems run with significant bugs for a 
long time' before they are detected. The clarity of documentation for 
the PDP/LSI-11 instruction set could still be improved after all these 
years. This sort of difference could be properly documented. 

Clearly, a set of verification programs is needed for testing C 
language implementations and different models of hardware. This sort of 
error should be detected during the porting of the system, not a long 
time afterwards. 

An opinion. 

Whether it be official or not, DEC’S negative attitude to UNIX sites 
helps no-one. This attitude exists in Europe as well as in Australia, 
and is far from beneficial. UNIX users who experience this won’t have 
much "brand loyalty' and are probably in a better position than most to 
change to cheaper hardware. A more professional attitude from DEC in 
this area produces a better service for the users of their equipment and 
DEC is likely to maintain its strong position as a supplier of UNIX 
hardware. This should benefit both parties at a very low cost. 
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Spontaneous Bernoulli 
A Structuralist Language ' 

Karlos Mauvtaque 

Department of Ergonomics and Aesthetics 
University of Chippendale at California (UCC) 


Ever since primitive man's first scratchings in the dirt there has been a 
need for a unification of thought. Previous unstructured life-forms lacked the 
appreciation of how true modularity could improve the quality of life and how 
long and tedious its variable qualifiers could be. 

But alas with the unification of primitive man's creativity came the 
stifling of inspiration. Life lacked that spontaneous zest that made those 
primitive scratchings into commercially viable software. 

UNIX'*' is really no more than a little pile of gravel - a by-product of those 

scratchings. C^ is a lot of carp,"* Pascal^* is a brand of sweets. Spontaneous 

Bernoulli must be the language for today, TUNAS" 5 the operating system for the 
post-Brezhnev Western world. 

The C language, a product of those keen lads at Bell^ Laboratories, has 
become popular because of the blatant immorality of many of its constructs. The 
ability to transform an arbitrary constant into a pointer to just about anything 
smacks of hedonism, the kind of unrestrained perversity that was the downfall of 
the Roman Empire. 

Pascal, a product of Nick and his cronies in collaboration with Control Dada 
Carporation, reeks of self imposed puritanism. Primitive man is not allowed to 
put his stick in the dirt just in case he gets it dirty. This sort of bondage 
and discipline denies the programmer the simple pleasures of initialised data, 
and the data types are only really suited to 60 bit sticks. 

Spontaneous Bernoulli is designed to be an aware, open, communicative 
language - a language for the occasional user or the potential addict. No side 
effects are known (nor are they tolerated). Its beauty lies in structure, its 
structure in form, the form is art and the art is beautiful. 

The non-euclidean structure of SB solves all of the problems of other 


1 UNIX is a big shop with lots of shelves. 

2 Delightfully unpredictable. 

’Cie' - Candice Burgermeistersinger, 

3 A carp is a freshwater fish (Bishop) 
with a funny head, 

4 Pascal is a trademark of Cadbury-Schweppes. 

5 It's the fish (Bishop) that John West reject. 

6 The klangorous timbre of the bell is due 

to inharmonic partials distressing the cochlea. 
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langauges proposed to solve all the problems of other languages. For example 
Discurrent Driclad, a language proposed by those valiant hacks at the University 
of Troll-hits, makes incorrect' suppositions about the habits of friendly little 
furry woodland animals. In fact the second term of axiom 9 should read; 


V»i 




Bushy Tail 

After all, not all of us can see it through the winter without a supply of nuts! 
Let us examine the consequences of this axiom. 

DD statement Purpose Result 


a ;= b 


Set a to the value of b 


Bind a to a function 
which returns the current 
value of b, invariant of 
future change of b. 


if i = j 


Test equality of i and j. 


Compare the equivalence 
of the function bindings 
of i and j. (Each of i 
and j being bound as 
above). 


stop(war); 


Rid the third world of 
all aggression. Unite 
the masses, striving for 
peace. 


Stop the program and head 
for the basement. 


I am sure you had no trouble experiencing the disorientation of that 
example. 
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What does SB have to offer? It is designed with the creative programmer in ,v 

mind. No abstraction is too frivolous for the silicon-chip hot-tub age that we C 

live in. Self indulgence is not only supported, it is actively encouraged. A /o 

marketing expert system system (MESS) allows the programmer an infinite choice , l j 

between a tight, up-market, chatty little number and a laid-back, middle-of-the- oc 
road lemon. 

R: 

Semantic and syntactic restraints are derived from the. programmers intent, 
This effectively eliminates many erors associated with traditional programming 
languages. U 

DC 

Spontaneous Benoulli, formal systems in informal terms. Try it, you'll like 
it. A 

15 
ie 
III 
! 1 
DO 
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Roster of Exhibitors 

Winter 1983 UNICOM Conference 


ABLE COMPUTER 

CALLAN DATA SYSTEMS 

DIGITAL EQUIPMENT CORP. 


1732 Reynolds Avenue 

2645 Townsgate Rd, 

129 Parker Street (PK03-1/M36) 


Irvine, CA 92714 

Westlake Village, CA 91361 • 

Maynard, MA 01754 


Attn: Robert T. Jones 

Attn: Kenn G. Morris 

Attn: Jack Richardson 


(714) 979-7030 

(805) 497-6837 

(617) 493-8207 

t! 

Booth #418 

Booths # 400, 402 

Booths # 310, 312, 314, 316 


AGS COMPUTERS, INC. 

CHARLES RIVER DATA 

DUAL SYSTEMS CORP. 


j 135 Spruce Drive 

SYSTEMS, INC. 

2530 San Pablo Avenue 


Mountainside, NJ 07092 

4 Tech Circle 

Berkeley, CA 94702 


Attn: Chad Henderson 

Natick, MA 01764 

Attn: Elizabeth Sumner 


(201) 654-4321 

Attn: W. Daniel DeLea, Jr., 

(415) 549-3854 


Sooth # 520 

i 

f 

(617) 655-1800. 1 

Booth #114 

Booth # 202 


ALCYON CORP. 


FORTUNE SYSTEMS CORP. 


(716 Production Ave. 

CODATA SYSTEMS CORP. 

300 Harbor Blvd. 


Ian Diego, CA 92121 

285 N. Woire Road 

Belmont, CA 94002 


Attn: Lovell C. Chase, Jr. 

Sunnyvale, CA 94086 .. 

Attn: Dan Elliston 


{619) 578-0860 

Attn: Rosemarie Calpin 

(415) 595-8444 


tooth # 519 

(408) 735-1744 

Booth #404 

Booth # 302 


ALTOS COMPUTER SYSTEMS 


GOULD S.E.L. 


*360 Bering Drive 

COMPUTER CONSOLES, INC. 

COMPUTER SYSTEMS DIVISION 


lan Jose, CA 95131 

1212 Pittsford-Victor Road 

6901 W. Sunrise Blvd. 


Attn: Glenda Stroup 

Pittsford, NY 14534 

Ft. Lauderdale, FL 33310 


'408) 946-6700 

Attn: Renee Wright 

Attn: Teri-Lisa Maidhof 


tooths # 511, 513 

(716) 248-8200 

(305) 473-1050 



Booth # 313 

Booths #113,115,117*119,121 


AMDAHL CORP. 

*051 Office Box 470 

COMPUTER TECHNOLOGY 

HEWLETT-PACKARD COMPANY 


4/S: 215 

GROUP-TELEMEDIA, INC. 

11000 Wolfe Road 


unnyvale, CA 94086 

310 S. Michigan Avenue 

Cupertino, CA 95014 

hat 

Utn: Joan Rogers 

Chicago, ILL 60604 

Attn: Neal Kuhn 


408) 746-7032 

Attn: Robert E. Hinchey 

(408) 257-7000 


both # 406 

(312) 987-4092 

Booths # 204, 206 

Booth # 407 

in 

iVIV CORP. 


HUMAN COMPUTING 

we 

Cummings Park 

CORVUS SYSTEMS 

RESOURCES CORP. 

A 

Coburn, MA 01801 

2029 O’Toole Avenue 

lOSt. Mary St., #401 

ice 

Utn: Ed Arsenautt 

San Jose, CA 95131 

Toronto, Ontario 

he- 

617) 933-1165 
ooth # 217 

Attn: C. Stenman 
(408) 946-7700 

M4Y1P9 CANADA 

Attn: Edward Borkovsky 


1 

Booths# 501, 503 

(416) 922-1937 


RS 


Booths # 101, 103 

nt. 

200 Route 7 

COSMOS SYSTEMS, INC.' 


ipg 

at ham, NY 12110 

525 University Ave., # A60 

IBM CORP. 

4tn: Tom Topolinski 

Palo Alto, CA 94301 

23rd Floor 


f!8) 783-1161 

Attn: Diane Doran 

425 Market Street 


both # 518 

(415) 326-9150 

San Francisco, CA 94105 


Booths # 505, 507 

Attn: Bill Clinton 


ADRE SYSTEMS, LTD. (415) 545-4634 


>542 Ventura Blvd., #205 

CYB SYSTEMS, INC. 

Booth # 500A 

f.erman Oaks, CA 91403 

6448 Hway, 290 E., #D-106 


hn; Karl KJessig 

Austin, TX 78723 

(MAGE NETWORK 

113) 789-8588 

Attn: Vicki Stogsdill 

1633 Bayshore Hwy, Suite 239 

both # 5(5 

(512) 458-3224 

Burlingame, CA 94010 


Booths # 317, 319 

Attn: John Copeland 



(415) 665-6426 



Booth # 600 
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INSTITUTE FOR ADVANCE! 
PROFESSIONAL STUDIES 
55 Wheeler Street 
Cambridge, MA 02138 
Attn: Dr.Donald D. French 
(617) 497-2075 
Booth #415 

INSTRUMENTATION 
LABORATORY INC.* 

PIXEL DIVISION 
113 Hartwell Ave. 

Lexington* MA 02173 
Attn: Laurel Dutcher 
(617) 861-0710 
Booth # 304, 306 

INTEL CORP. 

3065 Bowers Ave. 

Mail Stop SC 4-718 
Santa Clara. CA 95051 
Attn: Lucille Harris 
(408) 496-7162 
Booth #311 

INTERACTIVE SYSTEMS COc 
1212 Seventh Street 
Santa Monica, CA 90401 
Attn: Dwayne C. Lowry 
(213) 450-8363 
Booths # 508, 510 

INTERLAN INC. 

3 Lyberty Way 
Westford. MA 01866 
Attn: Gerald W. Wesel 
(617) 692-3900 
Booth #112 

INTERNATIONAL DATA 
SERVICES, INC. 

1020 Stewart Drive 
Sunnyvale, CA 94086 
Attn: Richard J. Cavanaugh 
(408) 730-UNIX 
Booth # 500 

LOGICAL SOFTWARE* INC. 

55 Wheeler Street 
Cambridge. MA 02138 
Attn: Douglas I. Kalish 
(617) 864-0137 
Booths # 41 i* 413 




MARK WILLIAMS COMPANY 

ONYX SYSTEMS, INC. 

RYAN-McFARLAND CORP. 

3 COM CORP. 

1430 V/. Wright wood 

25 E. Trimble Road 

9057 Soquel Drive 

1390 Shorebird Way 

Chicago, 1L 60614 

San Jose, CA 95131 

Aptos, CA 95003 

Mountain View, CA 9; 

Attn: Karen Gunn 

Attn: Mike Spies 

Attn: Barbara Fitzgerald 

Attn: Mike Flalaburka 

(312) 472*6659 

• (408) 946-6330 

(408) 662-2522 

(415) 961-9602 

Booth #219 

Booths #100,102,201,203 

Booths # 216, 218 

Booth # 514 

MASSCOMP 

PACIFIC 

THE SANTA CRUZ 

UNIQ COMPUTER C( 

543 Great Road 

MICROCOMPUTERS, INC. 

OPERATE*N INC. 

28 S. Water Street 

Littleton, MA 01460 

119 Aberdeen Dr., #7 

500 Chestnv. "treet 

Batavia, IL 60510 

Attn: Cathy Pfister 

Cardiff, CA 92007 

Santa Cruz, C. . 95060 

Attn: Roger A. Knuth 

(617) 486-9425 

Attn: John Metzger 

Attn: John Rigdon 

(312) 879-6515 

Booths # 301, 303 

(619) 436-8649 

(408) 425-7222 

Booth # 516 

METHEUS CORP. 

Booths # 305, 307 

Booths# 109, 111 

UNISOFT SYSTEMS 5 

5289 N.E. Etam Young Pkvvay 

PARALLEL COMPUTERS 

SOFTEST, INC. 

2405 4th Street 3 

Bldg. D-600 

501 Cedar Street 

555 Goffle Road 

Berkeley, CA 94710 

Box 1049 

Santa Cruz* GA 95060 

Ridgewood, NJ 07450 

Atm: Sharon Hill 

Hillsboro, OR 97123 

Attn: Scott D. Pine 

Attn: David Schneider 

(415) 644-1230 

Attn: Paul Chen 

(408) 429-1338 

(201) 447-3901 

Booth # 200 e 

(503) 640-8000 

Booth # 604 

Booths # 601, 602 

Booth # 110 

USER TRAINING COI C 


PERKIN-ELMER 

SOFTRON, an HHB COMPANY 

21565 Alma Court \ 

MICROSOFT CORP. 

2 Crescent Place 

116 Route 17 North 

Los Gatos, CA 95030 ^ 

10700 Northup Way 

Oceanport, NJ 07757 

Upper Saddle River, NJ 07458 

Attn: George Champag; 

Bellevue, WA 98004 

Attn: Emily Backus 

Attn: Suzanne Hartig 

(408) 354-6433 1 

Attn: Patricia McGinnis 

(201) 870*4717 

(201) 327-8014 

Booth #118 S 

(206) 828-8080 

Booths # 106, 207 

Booth #116 

£ 

Booths # 401, 403 



VENTURCOM, INC. 


PLEXUS COMPUTERS, INC. 

SOFTWARE IRELAND, LTD. 

139 Main Street , j 

MOMENTUM COMPUTER 

2230 Martin Avenue 

31 Anderson Way 

Cambridge, MA 02142 

SYSTEMS INTERNATIONAL 

Santa Clara, CA 95050 

Menlo Park, CA 94025 

Attn: Paul KJeppner 

965 W. Maude Avenue 

Attn: Leslie D. Schroeder 

Attn: Gordon Bell 

(617) 661-1230 - v 

Sunnyvale, CA 94086 

(408) 988*1755 

(415) 854-2383 

Booth#4i6 ' V 

Attn: Ron Grondona 
(408) 245*4033 

Booths # 417, 419 

Booth # 214 

LI 

VIRTUAL n 

Booths # 105, 107 

REALTIME SYSTEMS 

SUN MICROSYSTEMS INC. 

MICROSYSTEMS, INC 
2150 Shattuck Ave. * 


Elliott Terrace Workshops 

2310 Walsh Avenue 

NATIONAL 

Newcastle Upon Tyne 

Santa Clara, CA 95051 

Suite 720 

SEMICONDUCTOR CORP. 

ENGLAND NE4 6UP 

Attn: Ajay Puri 

Berkeley, CA'94704 2e 

2900 Semi Conductor Drive 

Attn: Bill Colwell 

' (408) 748-9900 

Attn: Ross Charrtey LI 

M/S 16250 

0632-733131 

Booth # 210, 212 

(415) 841-9594 

Santa Clara, CA 95051 

Booth #318 


Booth # 605 

Attn: William Brennan 


SYSTEM INDUSTRIES 


(408) 721-5752 

RELATIONAL DATABASE 

4440 Von Karman Ave., #200 

WICAT SYSTEMS, IN 1 ' e 

Booth # 517 

SYSTEMS, INC. 

Newport Beach, CA 92660 

1875 S. State 


1203 Apollo Way # 503 

Attn: Scot Leisy 

Orem, UT 84057 

NETWORK RESEARCH CORP. 

Sunnyvale, CA 94086 

(714) 851-6289 

Attn: Ken Sorber O 

1964 Westwood Blvd., #200 

Attn: O, D. Parkinson 

Booths # 410, 412 

(801) 224-6400 

Los Angeles, CA 90025 

(408) 746-0982 


Booth # 414 

36 

Attn: Howard Gordon 

Booth # 300 

TELETYPE CORP. 

(213) 474-7717 


47 Stonehenge 

YATES VENTURES 

Booths # 502, 504 

RELATIONAL 

Morristown, NJ 07960 . 

4962 El Camino Real M 


TECHNOLOGY, INC. 

Atm: Fred P. Hick 

Los Altos, CA 94022 

NORTH AMERICAN 

2855 Telegraph Ave., # 312 

(201) 538-6890 

Attn: Jeffrey Brown 

TECHNOLOGY, INC 

Berkeley, CA 94705 

Booth # 603 

(415) 96-4-0130 

9570 SAV. Barbur 

Attn: Debbie Muzio 


Booth 2L1 

Portland, OR 95825 

(415) 845-1700 

THIRD EYE SOFTWARE 


Attn: Roberta Donovan 

Booth # 606 

73»4 Webster Street 

ZILOG, INC. 

(503) 245-6585 


Palo Alto, CA 91301 

1315 Dell Avenue 

Booth #315 


Attn: Peter Rowell 
(415) 32H0967 

Booth # 405 

Campbell, CA 95008 
Attn: Carolyn Hayes 
(408) 370-8000 

Booths # 213, 215 
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CALL FOR PAPERS 


13TH EUUG MEETING 


PER CO! 
:et 
10 

Knuih 


11TH - 13TH APRIL 1983 


Wissenschaft Centrum, Old Town of Badgodesburg, BONN. 

; EMS £ 13th EUUG Meeting will take place in Bonn on the three days of 11th, 12th, 
i 13th April under the organisation of Hans Grimm, GMD (Gesellschaft fur 

14710 tbematik und Datenverarbeitung) . 

[ill 

e meeting will include special sessions on:- 

\'GCOR Unix System V by AT&T Managerial and Technical Staff, 
u rt virtual memory Unix (VAX et al), 

95030 personal Workstations (68000 systems et al), 
hampagn Development of the Unix filestore, 

Secure UNIX systems, 

European Network. 

. INC. 

v 02142^ te< ^ 9 peakers include the following: - 

pner 

sve Bourne, Bell Laboratories, 
vBirman, ex Berkeley Cocanet, now Cornell, 

LI Joy, SUN Microsystems, 

lNC fl LeffIer ' of Berkeley, who is taking over from Bill Joy, 

^ ve ’ ‘ Tanenbaum (held over from Leeds due to popular demand). 

54704 iers are invited from members on any of the topics mentioned above as 
-irney LI as : 


research on UNIX based projects 

ms, iN(' ec hnical descriptions of new UNIX software products, especially LAN and 
iatabase products, 

57 

3er on any topic likely to be of interest to the membership as a whole. 

J# ^ i ✓ 

?ers (or initial abstracts) (or simply offers to speak) should be 
URES iressed to: 

.» Real # 

94022 Hans Grimm 

GMD 

j Postfach 1240 

j 5205 San Augustin 

Badgodesburg 

a BONN West Germany 
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The following info, was received 
in response to a request for site 
details from hosts on the SUN. 

I have included phone numbers 
where these are known, so please 
feel free to call the respective 
sites for further details. 


food 

Food Technology, UNSW 
LSI 11/23 
Pertec D4000 20Mb 
AED floppy controller 
(8" dbl sided dbl density) 
Sanders Media 12/7 
HP7450A C A 4 plotter) 

UNIX level 6 AUSAM 

bio23 (662 2668) 

Biological Sciences, UNSW 
PDP 11/23 + FPU. 

RL02 

Tektronix 4662 plotter 
UNIX level 7 AUSAM 

agsm (662 0273) 

AGSM, UNSW 
VAX-780 
TU78, RP07 

CDC 9766 + Emulex SC21V 
Emulex CS-J1 
Centronics 6600 printer 
UNIX 4.1 BSD 

comm34 (662 3440) 

Faculty of Commerce, UNSW 
DEC PDP 11/34 
CDC 80Mb, AMPEX 80Mb 
Pertec Tape drive 
UNIX level 6 AUSAM 

comm40 (662 3680) 

Faculty of Commerce, UNSW 

DEC PDP 11/40 

RK05 

Pertec (20 megabytes) 

UNIX level 6 AUSAM 


physiol (692 2695) 

Physiology, Sydney Uni. 

PDP 11/23 
Q bus + qniverter 
RK05, Pertec dual RK05 
DEC dual cassette 
DEC paper tape 

DEC LPS lab. peripheral system 
Tektronix 4662 plotter 
Sanders Media 12/7 printer 
Talos digitizing tablet 
UNIX level 7 AUSAM 

civil (662 3034) 

Civil Engineering, UNSW 
PDP .11/40 
PERTEC disks 
UNIX level 6 AUSAM 

unswpower (662 2797) 

Elec. Eng., UNSW 
PDP 11/40 

RK05, RL02, DRllb . 

AR11, TA11 

UNIX level 7 AUSAM 

csu40 (662 3590) 

Comp. Serv. Unit, UNSW 
PDP-11/40 

RK05J, RK05F, RX01 
TUI 0 

XYll plotter 
LVll printer/plotter 
Centronix 6600 printer 
PC11, DP 11, DR11-B 
Ampex DM980 + AED 8000 
Unix level 6 AUSAM 

psych44 (692 3024) 

Psychology, Sydney Uni. 

PDP 11/44 with fpu. 

CDC 9762 + EMULEX SC21 
PERTEC t9640 + EMULEX TC11 
GT40, AR-11 
NDK-4000 

UNIX level 7 AUSAM 

eleevax ( 662 3781 ) 

Elec. Eng., UNSW 
VAX 11/780 
RP06, TU77 

Data Products B900 printer 
Datasystems PLP-11 
tektronix 4015-1 
UNIX 32v/4.1bsd mixture + AUSAM 
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cadvax (662 3781) 

Elec. Eng., UNSW 
VAX 11/780 

CDC 9766 via EMULEX SC21 
TU45, TS11, LPA11-K 
AED colour graphics terminal 
Ramtek monitor 
HP 7580a plotter 
HP 7221c flat bed plotter 
UNIX 32v/4.lbsd mixture J- AUSAM 

elec70a (662 3781) 

Elec. Eng., UNSW 
PDP 11/70 

CDC 9766 + EMULEX sc70 
TUI6, MDB DZ, LP05 
qume micro 5 
UNIX level 7 AUSAM 

elec70b (662 3781) 

Elec. Eng., UNSW — 

PDP 11/70 
RP04, TE16 
UNIX level 7 AUSAM 

dsl (662 3781) 

Elec. Eng., UNSW 
PDP 11/34A 

AMPEX DM9100 + MSC1100 
MDB DZ 

hp 2631a serial printer 
UNIX level 7 AUSAM 

srl (6623781) 

Elec. Eng., UNSW 
PDP 11/34A 
RL01 

UNIX level 7 AUSAM 

elec35 (662 3781) 

Elec. Eng., UNSW 
PDP 11/35 

AMPEX DM9100 + MSC1100 
UNIX level 7 AUSAM 

elec40 (662 3781) 

Elec. Eng., UNSW 
PDP 11/40 
RK05 

UNIX level 7 AUSAM 

melb (341 5225) 

Melbourne Uni. Comp. Sci. 

VAX 11/780 
RM03, TE16 

CDC 9766 + Emulex SC21V 
UNIX Melbourne Modified 4.1a bad 


PE3240 

CDC 'MSM 80' disk 
Ampex 40Mb 
selch, pasla 
2-line commux 
8-line commux 
800 bpi tape drive 
Data Set Adapter 
Line Printer (TALLY) 

A/D D/A converter 
Interprocess switch 
UNIX version 7 Berkelized 

mathvax (662 2067) 

Mathematics, UNSW 
VAX 11/750 
RM80, RM03, TSL1 
PERTEC T9640 
UNIX 4.1BSD + AUSAM 

uowcsa (282 463) 

Dept, of CS, Wollongong 
PE 3230 

MSM300 (CDC 9766) 300 MB dual po 
MSM80 80 MB dual ported discs 
9trk 800bpi 45ips 
Tektronix 4006 

servogor 281 flat-bed plotter. 

4 line sync link to UNIVAC 1100/ 
UNIX level / (a la wollongong) 

uowcsb (282 463) 

Dept, of CS, Wollongong 
PE 3230 

MSM300 300 MB dual ported disc 
Pertec 10MB 

UNIX level 7 (a la wollongong) 

Logica Cambridge ring 

Prince Henry Hospital (661 0111) 
11/44 
RL02 

Winchester 67Mb + Emulex SC21 
Cipher Streamer Tape + Emulex 
UNIX level 7 

mhd (6922104) 

Elec. Eng., Sydney Uni. 

11/34A 

RL01 

Priam 6650 Winchester + Emulex 
Cipher 75 ips 1600/800 bpi 
AED6200 dual density-single side 
Matrox 512x512 graphical display 
NDK-4000 printer 
UNIX level 7 AUSAM 
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UCC (692 3491) 

UCC, Sydney Uni. 

11/44 

AMPEX DM980 + EMULEX SC21 
TE10 

Printrex P600 600 1pm printer/pl 
Data Recognition optical marksen 
UNIX level 7 AUSAM 


basservax (692 2824) 

Comp. Sci., Sydney Uni. 
VAX 11/780 . 

RM03, TE16, KMC 11 

CDC 9766 via EMULEX SC21 

NDK 4000 printer 

TTY40 printer 

UNIX 32V + 4.1 BSD + AUSAM 


uccgraphics (692 3491) 

UCC, Sydney Uni. 

11/34 

Florida Data 600cps printer 

Versatec 2160A 18" printer/plott 

DIGIDATA 800/1600 bpi 

CDC 9762 + EMULEX SC21 

Evans & Sutherland Multi-picture 

UNIX level 7 AUSAM / RSX11-M 

uccps (692 3491) 

UCC, Sydney Uni. 

11/24 

UNIX level 7 AUSAM 

uccmc ( 692 3491 ) 

UCC, Sydney Uni. 

VAX11/780 
CDC 9766 

Systems Industries.9800 disc con 
Systems Industries SBI interface 
STC 800/1600/6250 bpi tape 
SI 9700 unibus tape controller 
UNIX (coming) / VMS 


basser40 (692 2824) 

Comp. Sci., Sydney Uni. 

PDP 11/40 

TS03, PERTEC 5Mb 

AMPEX DM980 + AED 8000 controll 

ABLE DMAX 16 

UNIX level 7 AUSAM 

graphics (692 2824) 

. Comp. Sci., Sydney Uni. 

PDP 11/34 

PERTEC 20Mb, ABLE DZ16 
UNIX level 7 AUSAM 

chemeng (692 3832) 

Chem. Eng., Sydney Uni. 

PDP 11/60 

CDC RM03 look alikes 
Pertec 20MB 
TU10, RX02 
PP11 (reader only!) 

TALLY 2000 
Sanders Media 12/7 
UNIX level 7 AUSAM 


• THE AUSTRALIAN Timdsy Bseombar 7 1812 COMPUTERS 



. From NICHOLAS RGTHWELL in New York 

■ THE Bell Laboratories’ 

Unix language for managing 
complex computer opera¬ 
tions is rapidly emerging as, 
the standard of the Ameri¬ 
can computer industry. 

This was helped last week by 
Hewlett-Packard deciding to 
offer the language as stand¬ 
ard on its new 9000 line, and 
the launch of several Unix im¬ 
plementing chip sets. 

And IBM has chosen its Se¬ 
ries 1 minicomputer series as 
the vehicle to launch a new 
operating system, Cpix, der¬ 
ived from Unix, and is ex¬ 
pected to move increasingly- 
towards the Bell-developed 
system. ■ l 
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From megatest!dre Sat Feb 12 19:34:48 1983 
Subject: Benchmarks of machines at Unicom 
Newsgroups: net.micro 


t 
n 
a 
£ 

n 

At UNICOM Yin Shih and I took the opportunity to run a simple benchmark out 
most of the machines on display at the vendor exhibit. This is an attemptu 
at organizing the results. k 

In any benchmark it is important to know 1) what the benchmark tests and 2)S■ 
whether you care about what the benchmark tests. An example of what Iu, 
would consider to be a poor benchmark for most purposes is the Whetstone. 
The Whetstone bashes away at transcendental functions, exercising floatingTi 
point load, add, and multiply instructions. Unfortunately it uses these 
instructions with a frequency seldom encountered even in "heavy floating 
point grinders" such as SPICE. So, to make a long story short, we're going 
to tell you what we did and what numbers we got, but we're not going toS' 
make any claims about which- machine is the "fastest” or "best buy." We~ 
aren't going to try to interpret the results. Just the facts, ma'am.Ai 
Also, we did this on our own and not as representatives of Megatest—sob 
flame at us but don't get mad at the company (the only company ENTIRELY 
composed of Dead Heads! Long Live net.gdeadj). ^ 

•J 

Now that we've covered our a**es, let's get to the fun part. 

v: 

w 

The benchmark (for better or worse) is: f 

(i 

R. 

Ft 


long i; 

for (i=0;i<1000000;i++); s 

printf("Done.\n"); 

e: 

This is obviously completely cpu bound and tests 32 bit integer arithmetic 
(or at least increment and compare). 


main( ) 
{ 


} 


We ran two tests. 

and 


These were: 

/bin/time cc tst.c 
/bin/time a.out 


VJ 

w> 

4 


The compile was quite i/o bound on most systems. Some machines which did 
very well in the loop had terrible disk access times. Others had p£ 
reasonable i/o but slow processors. ; 

V / 

The system configurations and prices stated below are, in most cases, as - ^ 
tested. In some cases the prices quoted us by the salesmen were for ocher 
configurations and that is given instead. In a few cases the information c 
was unavailable. These figures may be wrong, but we tried to be as x « 
accurate as we could be. "Total" is the sum of user and supervisor time for 
both tests. Significant digits are what "time" gave us except for "real" 
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have tacked a ".0" on the end of some numbers. The 
the Xenix ports on the TRS model 16, Apple LISA, 
after we had a discussion • with some Microsoft 
the TRS model 16 has a 30 Hz clock and "time" gave 
a factor of two for these machines because all 
them are object file compatible and they just transported 
over without recompilation. The Microsoft people were quite 


times where I seem to 
numbers were corrected for 
and Parallel 68000 systems 
folks. It seems that 
numbers that were off by 
c on three of 
:ernpt utilities 


knowledgeable and very helpful. Thanks, guys, 


id 2 )Some systems were running multiuser, so the "real" numbers shouldn't be 
iat lused for comparisons. 

L. 0116 < t It < I 1 H J 

atingThe numbers, m increasing total order: 


these 
a ting 




cc 


a 

.out 



going 

ng toSystem & OS 

Price 

Config 

real 

user 

supv 

real 

user 

supv 

Total 

H We 





0.18 




0.69 

a ' am ftmdahl 470/V8 
and VM 

na 

na 

5.49 

0.26 

1.29 

0.24 

0.01 



IRELY 






1.0 

0.8 

0.0 


BEL 32/87 

32V 

~$250K 

na 

10.0 

1.0 

2.5 

4*3 




blX 11/780 

na 

Emulex SC21 

28.0 

0.6 

1.8 

13.0 

3.9 

0.2 

6.5 

Wo FP accel. 


disk controller 








4.1BSD 


w/ CDC 9766s 








(courtesy of 


1-2MB memory 








ifick Kiessig at 


(Rick wasn't sure) 







? ortune Systems) 










lasscomp 

$28000 

dual 10 MHz 

5,0 

1.2 

2.1 

8.0 

7.5 

0.1 

10.9 

5111 + 


68000s (for 








ierke1ey 


VM) with a 








extensions 


4KB cache 

27 MB winch 




- 




imetic 

j 

| 


1 MB floppy 

512KB memory 
ascii terminal 








(AX 11/750 

$1 00K 

SC21 w/4 160MB 

10.0 

—0 . 9 

2.4 

9.0 

8.0 

0.3 

11.6 

i/o FP accel 


Fujitsu winch 








|. laBSD 

i 

j 

v. j 


2 MB mem 

Emulex DH 
(the system I'm 








h die 
s had 


using now) 





8.7 


12.7 

ierkin-Elmer 3210 $50K 

64 MB winchester 

6.0 

1.0 

2.8 

9.0 

0.2 

*7+Berkeley extensions 

512KB memory 








s, afSCCS 
othei 

matioi'arallei 68000 

$ 1 4K 

10MHz 68000 

20.0 

2.2 

3.4 

9.0 

7.6 

0.0 

13.2 

be aienix’ 


8 serial ports 








me foi 


Multibus 








"rear 


16MB winch 
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HP-9000 

HP-UX (Sill) 


Sun 

4.lcBSD 


Charles River 
UNOS 


Alcyon APX 
Regulus 


Codata 3300 
V7 


Pacific Micro 
Super Sun 
Uni soft V7 


Onyx C8002 

V7+Berkeley 

extensions 


1 MB floppy 
256KB memory 

$88000 10MB winch 26.8 2.4 6.8 

64MB winch 

2 MB memory 
512KB floppy 
plotter 

color graphics 

$29,500 Sun Terminal 14.6 1.4 4.5 

1 MB memory 
84MB winch 
DCD tape drive 
10 MHz 68000 
mouse and 
upgrade to 68010 
(The salesman said 
this would cost $2.5K) 


$19,400 12.5MHz 68000 26.7 6.1 3.4 

4KB cache 
1MB memory 
4 serial ports 
10 MB winch 
1MB floppy 
Versabus 


4.4 4.2 0.1 13. 


9.4 7.8 0.6 14. 

1 

l 

] 


\ 

6.3 5.7 0.2 15 .' 1 


$29000 512KB memory 17.0 2.7 1.0 14.0 13.1 0.0 16. 

winchester 
(size n/a) 

68000 

(speed n/a) 
streamer tape 
drive 
Q bus 

$14000 68000 20.0 3.6 4.5 11.0 10.5 0.1 18. 

(speed n/a) 

2 serial ports 
12 MB winch 
1 MB floppy 
320K memory 

$13,900 68000 30.0 3.5 4.6 11.0 10.5 0.1 18 v 

(speed n/a) 

20 MB winch 
1MB floppy 
Multibus 
256KB memory 


$17,000 4 MHz Z8000 13.1 2.4 3.9 13.5 13.2 0.1 19, 

20 MB winch 
DCD tape drive 
256KB memory 
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If AX 1 1/730 na 

4.1BSD 

^*Alcyon APS $9950 

Regulus 


. 14. 

[ilog S8000 $17000 

lodel 11 
leus (V7 + 
ierke1 ey 
^tensions) 


2-RL02 

memory 

drives 
size n/a 

14.0 

2.1 

4.1 

33.0 

14.3 

1.0 

21.5 

512KB 

memory 

19.0 

10.1 

0.3 

12.0 

11.4 

0.0 

21.8 


3 ser,ial ports 
10MB removable 
winchester 
8 MHz 68000+ 

68451 MMU 
1 wait state 

Z8001 28.0 2.2 4.7 16.0 14.9 0.1 21.9 

(speed n/a) 

18MB winchester 
DCD tape 
ZBI bus 
256K memory 


111os 586 $7990 

2 15.| enix 


iicat 68000 $17000 

Inisoft 

|7+SI I I+Berkeley 
0 16.1 


10 MHz 8086 18.0 1.0 4.3 17.0 16.7 0.2 22.2 

512K memory 

minifloppy 

10 MB winch 

5-8 users 

8 MHz 68000 26.0 2.8 5.8 15.0 14.7 0.1 23.4 

up to 3 users 
1 MB memory 
1 MB floppy 
15MB winch 


iltos 68000 $12990 

tenix 


8 MHz 68000 24.9 5.5 8.8 10.2 9.8 0.1 24.2 

20 MB winch 

512KB floppy 

16 serial ports 

512K memory 


1 18 , 


'ixel 

r 7 + Berkeley 
ixtensions 


j jg'lexus P/25 
'illl+PWB 


‘15-18K 


$16900 


'ortune 32:16 "$10000 
jg7 (unbundied)+ 
^tensions 


8 MHz 68000 
1 wait state 
512K memory 
20 MB winch 
2-1MB floppies 
4 serial ports 

Z8000 

(speed n/a) 
512KB memory 
32MB winch 
DCD tape 

5.5 MHz 68000 
5MB winch 
800KB floppy 


35.0 4.9 6.4 21.0 12.6 0.3 24.2 


24.6 3.7 3.4 17.2 17.1 0.1 24.3 


19.0 3.2 7.9 15.0 14.0 0.1 25.2 


nyx C8002A $15490 


6 MHz Z8000 


16.8 2.8 5.9 16.9 16.6 0.1 25.4 
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SI 11 


(speed n/a) 
256K memory 
5 serial ports 
20 MB winch 
DCD tape drive 


TRS Model 16 
Xenix 

"$10000 

68000 

(speed n/a) 
up to 3 users 
12 MB winch 

1 MB floppy 
256K memory 

24.0 

3.2 

6.0 

17.0 

16.1 

0.3 

Apple Lisa 
Xenix 

"$10000 

5 MHz 68000 

1 MB memory 

5 MB winch 

1 MB floppy 

60.0 

6.1 

7.6 

16.0 

12.1 

0.1 

Apple Lisa 
Unisoft . 

"$10000+ 
cost of 
second 
drive 
(n/a) 

5 MHz 68000 

1 MB memory 

2-5 MB winch 

1 MB floppy 

39.0 

5.3 

7.2 

15.0 

14.5 

0.1 

Dual 

$16660 

8 MHz 68000- 

21.0 

5.9 

6.1 

18.0 

17.2 

0.2 


Unisoft 

(reconfiguration 
rights cost $2000) 


(10MHz planned) 
S100 bus 
20 MB winch 
1 MB floppy 
512K memory 
4 users 


BBN C/60 
BBN Unix 


$53000 


8 users 
68MB disk 
512KB memory 
The salesman 
said this machine 
was running with 
C/70 microcode. 


Momentum Hawk $18000 
model 32/4 
V7+Berkeley 
extensions+f77 


6 MHz 68000 33.0 
(8 MHz planned) 

1 MB memory 
20 MB winch 
4 terminals 


IBM PC+Sritek "$8000 

68000 card 

Xenix 


8 MHz 68000 

1 wait state 
Davong 5 MB winch 

2 floppies 
512KB memory 


Intel 86/330X $16000 
Xenix 


8 MHz 8086 
Multibus 
2 users 


I 

H 

2p 


K 

'4 

2; 


2^ 


1 


9.0 1.4 1.9 27.0 26.0 0.1 29 


4.2 12.6 16.0 12.2 1.6 30 


38.0 8.9 14.8 11.0 10.6 0.2 34 


16.0 3.0 4.8 37.0 28.6 0.2 36 
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384 KB memory 
35 MB winch 


Cosmos Lyra $16500 
V7 (Sill planned) 

2 ! 


IBM PC ~$6000 

Hark Williams' 
2 Coherent 


68000 34.0 7.9 8.2 23.0 21.7 0.2 38.0 

(speed n/a) 

20 MB winch 
1 MB* floppy 
Multibus 
512K memory 
8 serial ports 

5 MHz 8088 26.0 

512K memory 
Corvus 10 MB winch 
IBM monochrome crt 


(est.) 26.8 26.0 0.5 39.5 

(est. 


National NS16000 n/a 

t. 1BSD 

2\ 

\ 

\ 

I 

f 

>DP ll/23Plus n/a 
?c )EC V7M-11 
' $1K per user 
license fee) 

|orvus Unixplex 
Inisof t 


6 MHz NS16032 37.0 

1.5MB memory 
20 MB winch 
DCD tape drive 
joystick and 
graphics display 

ll/23Plus cpu 26.0 
2-RL02s 

size of memory n/a 


8 MHz 68000 40.3 


"$13-14K 
OEMs only 512KB memory 

2 serial ports 
10 MB winch 


2 ? 


4.4 15.5 21.1 19.6 0.6 40.1 


3.3 8.3 30.0 29.2 0.2 41.0 


3.5 35.0 14.2 12.5 1.6 52.6 


le would appreciate any additional information or corrections to this list. 


Dave Emberson 
Megatest Corp. 

477 Potrero Rd. 

3 ( Sunnyvale, CA 94086 

ucbvax!lbl-csam!megatest!dre 
i 


Yin Shih 
Megatest Corp. 

477 Potrero Rd. 

Sunnyvale, CA 94086 

ucbvax|lbl-csam!megatest!yin 


5 

f 


3< 


f 


3f 
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From sdchema! jmcg (Jim McGinriess) Thu Jan 13 20:34:41 1983 
Subject: UNICOM Keynote Speech—Abstract and Bibliography 
Newsgroups: net.usenix 


Software Army on the March - 
Project Strategies and 'Tactics 


John R Mashey 
Bell Laboratories 
Whippariy, NJ 07981 

This talk describes the work of an army building roads ( software projects ) 
through a part of the countryside that: 


* seldom has current maps. 

* is plagued by earthquakes ("major environment changes”), flash floods 
("temporary problems"), and fog ("inability to predict the future ). 

* contains villages of natives ("users") who may greet roadbuilders with 
anything from great interest to outright hostility, but whose coopera¬ 
tion is essential. 

* may be overrun by enemy forces ("competitors") trying to build their own 
roads to the same locations. 


An effective campaign has two aspects: 


* Doing the right thing, i.e., fighting the right war in the right place, 
and choosing good routes to reach the goals. 


Doing it right, i.e., building maintainable roads with adequate capa 
city, at a reasonable cost, without losing too many casualties, and 
without offending the natives. 


Most software methodologies emphasize the second part; this talk emphasizes 
the first by examining decision processes and methods of analyzing routes. 
Two different veiwpoints are used. The first is the formal game theory 
viewpoint—making decisions in a nondetermimstic, multi stage, N person 
non-zero-sum game* played with incomplete information. e s ^ con * , 

"army" model described above. From this viewpoint, will be discussed such 

issues as: 


* The need for scouts on motorcycles ("fast prototypers"). 

* How campaigns differ, and thus affect choice of troops, ranging from 
commando raids through the march of the hordes. 


* Special precautions for earthquake territory. 

* Getting natives to buy and drive your trucks, instead of shooting your 
tires out as you drive through their villages. 


There exist many similarities in the decision processes of formal games 
analysis, military planning, and project management This talk uses the 
first and second to help shed light on the third. Provided with the talk is 
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a n annotated bibliography, which includes a famous treatise on "project 
management" written in 500 B.C. 
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counter-implementation. Good reading for any software designer who 
hopes to sell ideas. Includes good bibliography. 

LEH80A Lehman, 'M. M. Programs, Life Cycles, and Laws of Software Evolu¬ 

tion. Proc. IEEE 68, 9 (Sep 1980), 1060-1076. 

S-, P-, and E-programs; use of methods to predict release effects. 

LUC57A Luce, R. D., Raiffa, H. Games and Decisions — Introduction and 
Critical Survey, Wiley, New York, 1957. 

Chapters 1, 3, 4, 7, 8 form a reasonable introduction to the topic. 

MAC68A Macksey, M. C. Panzer Division — The Mailed Fist. Ballantine 

Books, New York, 1968. 

History of German tanks in WW II. 

Moral: when youlre even or ahead, don't stop, somebody is gaining 
on you. When you're behind, be careful how you try to catch up. 

MAR82A Martin, J. Applications Development Without Programmers. Pretice 
Hall, Englewood Cliffs, NJ, 1982. 

Illustrates existing methods and tools for 10- to 100-fold produc¬ 
tivity improvements over conventional methods, for some problem 
domains. In some cases, normal high-level language coding appears 
to be pathetically absolete. 

PYS82A Pyster, A., Boehm, B. W. The Impact of Rapid Prototyping on 
Software Development Standards. In Proc. . ACM SIGSOFT Software 
Engineering Symposium: Rapid Protoyping, Columbia, MD, April 19-21, 
1982, paper #28. 

TRW huilds Software Productivity System on UNIX with fast prototyp¬ 
ing. 

TAY82A Taylor, T., Standish, T. A. Initial Thoughts on Rapid Prototyping 
Techniques. In Proc. ACM SIGSOFT Software Engineering Symposium: 
Rapid Protoyping, Columbia, MD, April 19-21, 1982, paper #40. 

Some parts are a bit academic, but has some good overall thoughts 
on prototyping, especially the section "Limits of Prototyping" on 
page 13. 

TZUXXA Tzu, Sun. The Art of War. 500 B.C. Military Service Publishing 
Company, Harrisburg, PA, 1944. [thanks to L. Bernstein] 

Contains numerous pithy discussions of project management, although 
not expressed in the standard terminology. 

"When you engage in actual fighting, if victory is long in coming, 
then men's weapons will grow dull and their ardour will be dam¬ 
pened,... Thus, though we have heard of stupid haste in war, clev¬ 
erness has never been associated with long delays." 

"[Frederick the Great, in his Instructions to his Generals, says 
'Those generals who have had but little experience attempt to pro¬ 
tect every point; while those who ate better acquainted with their 
profession, guard against decisive blows at decisive points, and 
acquiesce in smaller misfortunes to avoid greater. 1 ' In other 
words, keep away from sideshows.]" 
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WEI82A Weiser, H. Scale Models and Rapid Prototyping. In Proc. ACM SIG- 
SOFT Software Engineering Symposium: Rapid Protoyping, Columbia, 
MD, April 19-21, 1982, paper /42. 

Offers clear characterization of 3 different kinds of' prototypes: 
user interface, functionality, and performance. 
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Date: 19 Nov 1982 1655 (Friday) 

From peteri'.usa Thu Nov 18 15:42:00 1982 
To: kev chris piers davec 
Subject: system V 

System V was announce on Tuesday, publically. Release 1st quarter next 
year. "AT&T will actively assist licensees with serveral levels of 
software support including hotline service, consultation, technical 
seminars, newsletters, electronic mail to report problems and periodic 
releases to correct problems. 

"this new release reflects our response to users of UNIX systems who 
have indicated a desire to have the most current version available to 
the. 

"Software support also addresses concerns which system users have raised 
in the past" 

"UNIX System V will be offered as a machine-independarit standard 
operating system for 16-bit and 32bit computers. Details will be 
announced in January, 1983. 

Future releases will be upward compatable with UNIX system V. 

Bell/Western is now in the software business. Hope they make out. 

pete 


From harpo!decvax!aps:usa Wed Feb 9 20:21:53 1983 
To: harpo!mhtsa!australia!dave:csu40 
Subject: DEC announcement of VAX UNIX 

Basically, DEC has announced that it will sell and support UNIX on 
the VAX line of computers. (In December at DECUS, DEC announced that 
it would support V7M-11 on its PDP-11 line of computers. V7M-11 comes 
from the older DEC distribution V7m which is based on V7.) Before 
the end of the year, DEC will start selling and supporting a Berkeley 
(most probably 4.1) based VAX UNIX product with some of the features 
and things from System III/V that people seem to like or think they 

need (VPM, SCCS, etc). If 4.2 is at a point where it is stable 

before then (timming problems) DEC may go directly to 4.2 at the onset. 
No matter which BSD is used (4.1 or 4.2), DEC will go to 4.2 eventually. 

It is felt that we should wait until 4.2 has had time to settle out 

and "get the bugs out". Please feel free to pass this information on 
to others in Australia. Note that these offerings will be available 
only to the U.S. at first. 

aps. 
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